home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11508 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.2 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 14 Mar 1996 15:45:24 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4ia41k$e04@solutions.solon.com>
  8. References: <00001a73+00002504@msn.com> <3146E324.5C1E@lfwc.lockheed.com> <4i98gg$8n1@solutions.solon.com> <Do9tMv.2p3@world.std.com>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <Do9tMv.2p3@world.std.com>,
  12. Robert A Duff <bobduff@world.std.com> wrote:
  13. >There's some misinformation going on here.  The Ada RM does *NOT*
  14. >require a particular compilation order.  Neither does C.
  15.  
  16. I had been worried about that; the post I was responded to made me think
  17. Ada cared, which seemed odd.
  18.  
  19. >What Ada *does* require is consistency.  If two units refer to a third
  20. >unit, then they have to refer to the same version of the third unit (or
  21. >compatible versions of it).  This is really necessary in C, too, when
  22. >using include files, the difference being that Ada compilers are
  23. >required to tell you about inconsistencies, whereas C compilers are not.
  24.  
  25. To be specific, C compilers are required to tell you about *some*
  26. inconsistencies.  There's a clever trick with externs that lets you get
  27. this checking, and have the diagnostic be required.
  28.  
  29. >The problem
  30. >with 'make' is that you have to type in the dependences by hand.
  31.  
  32. Not always; there is a program which does this, although I personally never
  33. use it.
  34.  
  35. >But
  36. >nothing about C requires the use of 'make' -- it is entirely possible to
  37. >have a more automatic tool.  IMHO, direct use of 'make', with
  38. >hand-written make files, is the wrong approach for C or Ada or any other
  39. >language (unless you have fewer than about 5 files in your program).
  40.  
  41. I actually do fine with make for even moderately large projects (by my
  42. standards).  A well done make (NetBSD has one I respect) can handle quite
  43. large projects.
  44.  
  45. >So, neither C nor Ada give you what you really want -- a tool that
  46. >automatically builds your program.  So I don't think you can argue that
  47. >either language is better than the other in this regard.  This is fine
  48. >-- it's not necessary to specify every imaginable Good Thing as part of
  49. >your *language* standard.
  50.  
  51. Damn straight.
  52.  
  53. >You could argue that Ada is better because it complains when there's an
  54. >inconsistency.  Fine, but for a large program, it's a nightmare to
  55. >figure out what to *do* about that inconsistency, unless you have an
  56. >automatic tool (not 'make').  So, in practice, you need a separate tool
  57. >anyway, and if you use it religiously, you won't get burned by
  58. >inconsistencies in *either* language.
  59.  
  60. As noted, C can detect some inconsistencies, and this can be a
  61. very nice trick.
  62.  
  63. My general strategy is to just rebuild everything after any significant
  64. change.  CPU time is cheap during the build process.  I have more processor
  65. time than hair.  (And I'm one of them hippie longhairs, too.)
  66.  
  67. -s
  68. -- 
  69. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  70. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  71. FUCK the communications decency act.  Goddamned government.  [literally.]
  72. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  73.